home *** CD-ROM | disk | FTP | other *** search
Text File | 1990-05-18 | 1.7 KB | 44 lines | [TEXT/GEOL] |
- Item forwarded by PHAC to DOUGLASS1 MEIER1
-
- Item 9622631 15-May-90 15:52PDT
-
- From: ROSENSTEIN1 Rosenstein, Larry
-
- To: CDA0004 VAR Shana Corp, Don Murphy,IVR
- MACAPP.TECH$ MacApp Technical
-
- Sub: RE>UnloadAllSegs
-
- Attn: Wayne Malkin
- Attn: MacApp Tech
- SentBy: Larry Rosenstein
- Reply to: RE>UnloadAllSegs
- Wayne,
-
- I don't think the failure handling code is suppose to work if you return from
- the routine that calls CatchFailures, for the reason you gave. We did a
- special case hack for the MacApp startup code where the handler is set up in
- one place and removed when initialization is complete. Other than that, you
- must call Success in the same routine that you call CatchFailures.
-
- You can use global routines for the failure handler, and call CatchFailures in
- a global routine.
-
- It seems that your technique might result in heap fragmentation, although it
- will reduce the maximum amount of loaded code. Perhaps the heap fragmentation
- isn't a problem compared to the benefit of the reduced code reserve. You can
- also eliminate that by explicitly preloading segments that you know won't be
- unloaded.
-
- Also, if someone didn't want to modify the MacApp segment-handling code,
- MacApp does provide all the tools necessary to manage the application's code
- segments. If you know the situation(s) in which the maximum loaded code is
- excessive, you can temporarily mark segments as resident and call
- UnloadAllSegments in the middle of an operation (rather than waiting until you
- return to the event loop). Your approach has the advantage of being
- automatic.
-
- Larry
-
-
-